[素朴な手順]EBSスナップショットからファイル復旧してみます

ベルリンのはんせです 題名のままですが、EBSスナップショットからファイル復旧する方法についてバババっと手順紹介したいと思います。

はじめに

EC2を使う上でもかなり基本的な内容で、当ブログでも何度か紹介されていますが、

• スナップショットによるEC2インスタンスのバックアップとレストア | Developers.IO
• EBSスナップショットからのレストア | Developers.IO

最近でも本番インスタンスでファイルを誤削除してしまったという相談を受けることがありました。 急ぎの作業や夜中の対応で「やってしまった」という時に参照されるといいなと思います。

やってみます

作業環境はAmazon Linuxです。windowsはまたいつか。。

下準備：ディレクトリを誤削除します

/home/testというディレクトリでオペミスしたと仮定します。 ディレクトリの中身。4ファイルが格納されています。

[ec2-user@ip-172-xx-xx-xx ~]$ ls -l /home/
合計 8
drwx------ 3 ec2-user ec2-user 4096  3月  1 18:20 ec2-user
drwxr-xr-x 2 ec2-user ec2-user 4096  3月  1 11:45 test
[ec2-user@ip-172-xx-xx-xx ~]$ ls -l /home/test/
合計 16
-rw-rw-r-- 1 ec2-user ec2-user 2  3月  1 11:45 test1.txt
-rw-rw-r-- 1 ec2-user ec2-user 3  3月  1 11:45 test2.txt
-rw-rw-r-- 1 ec2-user ec2-user 4  3月  1 11:45 test3.txt
-rw-rw-r-- 1 ec2-user ec2-user 5  3月  1 11:45 test4.txt
[ec2-user@ip-172-xx-xx-xx ~]$ sha256sum /home/test/test*
87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c7  /home/test/test1.txt
a63d8014dba891345b30174df2b2a57efbb65b4f9f09b98f245d1b3192277ece  /home/test/test2.txt
edeaaff3f1774ad2888673770c6d64097e391bc362d7d6fb34982ddf0efd18cb  /home/test/test3.txt
fc4b5fd6816f75a7c81fc8eaa9499d6a299bd803397166e8c4cf9280b801d62c  /home/test/test4.txt

で、、、

[ec2-user@ip-172-xx-xx-xx ~]$ sudo rm -rf /home/test
[ec2-user@ip-172-xx-xx-xx ~]$ ls -l /home/
合計 4
drwx------ 3 ec2-user ec2-user 4096  3月  1 18:20 ec2-user
[ec2-user@ip-172-xx-xx-xx ~]$ ls -l /home/test
ls: /home/test にアクセスできません: そのようなファイルやディレクトリはありません

やってしまいました。

復旧手順：既存のファイルシステムの確認

今回はAMIからまるっと復旧可能なケースではなく、稼働中サービスに影響が無いよう、必要なファイルだけを取り出して再配置したい場合を想定します（サービス復旧の観点から、AMIからインスタンスごと入れ替えることができればそちらの方が早いです）

というわけで、ファイルが存在していたボリュームを確認します。

[ec2-user@ip-172-xx-xx-xx ~]$ df -T
ファイルシス   タイプ   1K-ブロック    使用  使用可 使用% マウント位置
devtmpfs       devtmpfs      499580      56  499524    1% /dev
tmpfs          tmpfs         508544       0  508544    0% /dev/shm
/dev/xvda1     ext4         8123812 1062152 6961412   14% /

念のため作業対象のインスタンスIDも確認しておくとオペミス防止になると思います。

[ec2-user@ip-172-xx-xx-xx ~]$ curl http://169.254.169.254/latest/meta-data/instance-id/ && echo
i-010d6bxxxxxxxxxxxx
[ec2-user@ip-172-xx-xx-xx ~]$ exit
ログアウト
Connection to xx.xx.xx.xx closed.

復旧手順: 取得済みのAMIを確認する

取得日付などからオペミス前のAMIを確認します。（バックアップを取っていなかったらこの時点で完。

ありました。「Block Devices」の項目からsnapshotのIDも確認できます。

復旧手順: AMIからオペミス前のVolumeを作成

snapshotから作成します。IDから対象のsnapshotを見つけて「Create Volume」を実行

Create Volumeの画面。復旧先のインスタンスにアタッチするため、同じAvailability Zoneを指定する必要があります。他は特に選択をせず「Create Volume」をクリックします。

Volumeはすぐに作成され、availableの状態になっています。

復旧手順: Instanceの停止とボリュームアタッチ

停止中のインスタンスにしかアタッチができませんので、インスタンスを停止します。

インスタンスが停止できたらVolumeをアタッチします

アタッチ先のデバイスは /dev/sdb を指定します。

Instances画面でBlock Devicesに /dev/sdb が入っていることを確認します。

アタッチできていることが確認できましたので、インスタンスを起動

復旧手順: マウントとファイル取り出し

インスタンスにsshログインし、アタッチしたボリュームをマウント

[ec2-user@ip-172-xx-xx-xx ~]$ df 
ファイルシス   1K-ブロック    使用  使用可 使用% マウント位置
devtmpfs            499580      64  499516    1% /dev
tmpfs               508544       0  508544    0% /dev/shm
/dev/xvda1         8123812 1062488 6961076   14% /
[ec2-user@ip-172-xx-xx-xx ~]$ sudo su - 
[root@ip-172-xx-xx-xx ~]# curl http://169.254.169.254/latest/meta-data/instance-id/ && echo
i-010d6bbfcc1fc4589
[root@ip-172-xx-xx-xx ~]# mkdir /mnt/temp
[root@ip-172-xx-xx-xx ~]# mount -t ext4 /dev/sdb1 /mnt/temp
[root@ip-172-xx-xx-xx ~]# ls -l /mnt/temp/
total 120
dr-xr-xr-x  2 root root  4096 Jan 15 18:43 bin
dr-xr-xr-x  4 root root  4096 Jan 15 18:43 boot
drwxr-xr-x  2 root root  4096 Feb 28  2014 cgroup
drwxr-xr-x  2 root root  4096 Jan 15 18:43 dev
drwxr-xr-x 78 root root  4096 Mar  1 11:38 etc
drwxr-xr-x  4 root root  4096 Mar  1 11:43 home
dr-xr-xr-x  7 root root  4096 Jan 15 18:42 lib
dr-xr-xr-x 10 root root 12288 Jan 15 18:43 lib64
drwxr-xr-x  2 root root  4096 Jan 15 18:42 local
drwx------  2 root root 16384 Jan 15 18:42 lost+found
drwxr-xr-x  2 root root  4096 Jan  6  2012 media
drwxr-xr-x  2 root root  4096 Mar  2 20:02 mnt
drwxr-xr-x  3 root root  4096 Jan 15 18:43 opt
drwxr-xr-x  2 root root  4096 Jan 15 18:42 proc
dr-xr-x---  3 root root  4096 Mar  2 20:01 root
drwxr-xr-x  3 root root  4096 Mar  1 11:38 run
dr-xr-xr-x  2 root root 12288 Jan 15 18:43 sbin
drwxr-xr-x  2 root root  4096 Jan  6  2012 selinux
drwxr-xr-x  2 root root  4096 Jan  6  2012 srv
drwxr-xr-x  2 root root  4096 Jan 15 18:42 sys
drwxrwxrwt  3 root root  4096 Mar  2 20:02 tmp
drwxr-xr-x 13 root root  4096 Jan 15 18:42 usr
drwxr-xr-x 19 root root  4096 Jan 15 18:43 var

良さそうです。削除してしまったファイルを確認します

[root@ip-172-xx-xx-xx ~]# ls -l /mnt/temp/home/test/
total 16
-rw-rw-r-- 1 ec2-user ec2-user 2 Mar  1 11:45 test1.txt
-rw-rw-r-- 1 ec2-user ec2-user 3 Mar  1 11:45 test2.txt
-rw-rw-r-- 1 ec2-user ec2-user 4 Mar  1 11:45 test3.txt
-rw-rw-r-- 1 ec2-user ec2-user 5 Mar  1 11:45 test4.txt
[root@ip-172-xx-xx-xx ~]# sha256sum /mnt/temp/home/test/test*
87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c7  /mnt/temp/home/test/test1.txt
a63d8014dba891345b30174df2b2a57efbb65b4f9f09b98f245d1b3192277ece  /mnt/temp/home/test/test2.txt
edeaaff3f1774ad2888673770c6d64097e391bc362d7d6fb34982ddf0efd18cb  /mnt/temp/home/test/test3.txt
fc4b5fd6816f75a7c81fc8eaa9499d6a299bd803397166e8c4cf9280b801d62c  /mnt/temp/home/test/test4.txt

問題なさそうです。あとは元にあった場所にcpなりsyncなりをすれば完了です。

後しまつ: アンマウントとインスタンスのデタッチ

作業が完了したら、追加したボリュームの役割は終わりましたので、アンマウントを実行します

[root@ip-172-xx-xx-xx ~]# umount /mnt/temp/
[root@ip-172-xx-xx-xx ~]# mount
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=499580k,nr_inodes=124895,mode=755)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,relatime)
/dev/xvda1 on / type ext4 (rw,noatime,data=ordered)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)

アンマウントしたらボリュームのデタッチをしましょう。デタッチはRunnnigステータスのインスタンスに対しても可能です。また、強制的にデタッチ（Force Dettach）を実行しても問題ないかと思います（復旧用のEBSボリュームは使用しないため） インスタンスからの Amazon EBS ボリュームのデタッチから

ボリュームの状態がdetaching状態のまま変わらない場合は、[Force Detach] を選択して、強制的にアタッチ解除することもできます。障害が発生したインスタンスからボリュームをアタッチ解除するための最後の手段として、またはボリュームを削除するためにデタッチする場合のみ、このオプションを使用してください。インスタンスは、ファイルシステムキャッシュやファイルシステムメタデータをフラッシュする機会を失います。このオプションを使用する場合は、ファイルシステムのチェックと修復の手順を手動で実行する必要があります。

数分間で複数回、ボリュームのdetachingを強制実行しても、デタッチ状態のままの場合、Amazon EC2 forum にヘルプの要請を投稿できます。迅速に解決できるようにするため、ボリューム ID と、これまでに実行した手順を記述してください。

デタッチ済みのEBSボリュームは不要なため、削除しましょう。

最後に

AWSでも様々なデプロイサービスが提供されていますが、 - AWSでデプロイとスケーリングを自動化する方法まとめ | Qiita

一方で、簡素なインフラ構成で運用されているサービスもまだまだあると思います（昔からの運用を続けているなど）。 Ec2のリブートなしでAMI取得は可能ですので、作業前には必ずAMIを取得しましょう。 定期的にAMI取得ができているか・復旧手順があるか、もう一度確認しましょう。

※ 参考: Amazon EBS-Backed Linux AMI の作成 | Amazon Elastic Compute Cloud

それでは〜